This distinction is unclear to me -- is it proposing that clinician-supplied details like dosing would not be passed along with this hook? I'm concerned that we're deprecating a simple model (an in-progress hook that re-fires any time an in-progress order changes) in favor of a complex model (#418) *but we've only introducing support for one step of the complex model.

This strikes me as a net reduction in functionality without simplifying the problem.

it is possible I have misunderstood the intention of this hook, in which case it would be good to clarify here and in the definition.

Hey @jmandel ,

I think that you definitely understand the intention of this hook. It fires as early as possible in the ordering workflow and will not contain clinician-specified details. It's contrasted with the order-sign, which fires at the last possible step in the ordering workflow and does contain all details.

an in-progress hook that re-fires any time an in-progress order changes

Neither med-prescribe nor order-review are documented nor, per my impression, understood nor implemented to behave in the way you're describing (frequent re-firing).

The Jan, 30th CDS WG call talked through a potential order-accept hook which would implement an additional middle step between order-select and order-sign and represent some intermediate point at which the provider tentatively accepted order details, but before she signed.

@jmandel / @isaacvetter - What if this hook was invoked both when then order is first selected and then also can be invoked each time the clinician specifies/selects a new detail?

FWIW, Cerner's current CPOE functionality today only triggers CDS when the order is first selected and then upon signing the order. So, exactly as how @isaacvetter has proposed here today. So, we wouldn't be able to support this in-progress hooking today.

Neither med-prescribe nor order-review are documented nor, per my impression, understood nor implemented to behave in the way you're describing (frequent re-firing).

FWIW, the sandbox implements them this way -- which is "code as documentation". (Seriously though, it's been the only way that developers have been able to use/test the functionality, so it's what people expect/believe about how the hook works.)

From my perspective right now, this change is introducing a more complicated system and reducing functionality. I can be led to reason, though! Could you help articulate the value it's introducing?

@jmandel - What I was trying to ask/propose is what if we documented order-select at behaving in the way you describe but keep flexibility if a CPOE system only wanted to invoke order-select when the user first selects the order. Basically, I'm trying to strike a balance between the reality of some major CPOE systems today and what a re-envisioned (or newer) CPOE system should be capable of doing.

We're talking in circles :-)

I obviously think the behavior is important even if it has historically been under-specified. I'm trying to prevent the behavior from be being specified out of existence, by instead clarifying our language in a way that affirms the behavior.

if it keeps popping up an alert

In my opinion, very little or none of this advice should ever pop up an alert; that's up to each CDS client to define, of course. In any case, I think we both agree that popping up alerts in the middle of workflow makes for a frustrating UX.

To be clear, @kpshek's proposed language wouldn't require you to re-trigger the hook if you thought it would mean a performance hit within your system. It proposed an option.

Re: applying decision support at order signing, this is in my opinion a very late stage at which to be introducing changes to a dose. Much better to provide feedback early and often (and ambiently, rather than interruptively, if I can use adjectives loosely).

Yes, it is a proposed option that wouldn't require re triggering every time. But the option was discussed in the HL7 call, and as far as I could tell there were two conclusions

1. it was preferred to have a separate order-detail-select / order-accept hook. If we do that, then @kpshek 's proposed language will conflict with that hook. So if this need is there, a separate hook needs to be written up.
2. There did not seem like there was an urgent need for this hook during the call. At least it did not to me, and it was agreed that the order-select and order-sign hooks can be published and marked as deprecating medication-prescribe and order-review without this new hook being written up. The writing up of the new hook can be deferred till later, until good thought and use-cases can be factored into it.

(Also, pop-up vs, a div that appears in line is not very different with regard to distraction. I meant them all by one appellation of popup).

PS: Josh, I myself was the person who suggested in the HL7 call that we should allow order-select hook to fire at the time of accepting order edits. I was convinced by others in the call that a spearate hook is the better option. It's in the minutes:

Matt – EHR could implement order-select hook at time of accept as well

Based on my own comment in the pull request for order-sign #429 (comment), I am withdrawing my disagreement with adding the below to the description of order-select in the interest of closure.

If supported by the CDS Client, this hook may also be invoked each time the clinician selects a detail regarding the order.

Awesome!

@jmandel, when you get a chance, will you please re-review/approve and resolve, if appropriate?

Then I'll merge ... and we'll have our first proposed hook since 2015 or so! 🎉